FIG. 1 shows schematically the functioning and the context of Random Handback Authentication (RHA), the principle of which being used in the invention.
The RHA exposes similar property as RSA. It uses a legacy encryption/decryption principle as the AES but presents the advantage not to implement algorithms based on modular exponentiation.
The aim is to establish a secure channel between two entities eA and eB each belonging to two different groups A and B having each an identifier IDGrA and IDGrB. Typically entities are smart phones, wearable devices as smart watches interfacing Internet Of Things (IoT) devices . . . All devices of a same group A or B is provided with a group key KA or KB.
FIG. 1 shows an initialization phase during which each device eA and eB generates respectively a random R0A and R0B. Such an initialization phase is performed by all devices of all groups.
This random R0i is then encrypted using the group key Ki in order to produce a cryptogram C0i. In the example given on FIG. 1, C0i=AES[Ki](R0i).
An authentication token T0i is then produced comprising the cryptogram C0i and the random number R0i. 
In the initialization phase, a secure channel is established using a classical technology in a step S00. In the presented example, a secure channel based on PKI is used. This step, which is generally time-consuming and anyhow more time-consuming than the invention, is done once. In the example given on FIG. 1, the provision of the first token, T0B and T0A, of the other group B and A, identified by identifiers IDGrB and IDGrA, is done by pair between two devices in a step S01. In practice other implementations can use a provision performed by a central group A authority establishing secure channels with any device from other groups B authorized to communicate with devices from the group A.
At the end of initialization phase, each device has received a token T0i=[IDGri, C0i, R0i] from any other group it is intended to communicate with. When several tokens are successively received, the last is kept to serve at the next connections.
FIG. 2 shows schematically a token TNi as stored after a N-th connection with an entity of the group i. This token TNi has been generated by an entity ei of the group i. It comprises a random number RNi which may contain hidden and non-forgeable information as an operation code (revocation, or certificate checking operation), a timestamp limiting the validity or starting the validity at a given date or a duration, a count.
In the given example, the random number RNi comprises an operation code OPC, a random number RND and a time stamp or counter TS. The random number RNi can be further encrypted before calculation of a cryptogram CNi using the group key Ki with the key of the originator of the RHA authentication token. The token TNi comprises the random RNi and the cryptogram CNi.
FIG. 1 also shows how the authentication operates during subsequent connections between the entity eA and the entity eB. In the example shown on FIG. 1, entity eA established previously N connections with an entity of the group B before requesting the connection with entity eB. The entity eB established, on its side, Z preceding connections.
In a step S10, the two entities exchange group identifiers. Entity eA sends the identifiers of its group IDGrA and symmetrically for entity eB. In a step S11, the two entities exchange the cryptogram they have for the group of which they received the identifier IDGr. Entity eA thus sends to entity eB the cryptogram CNB and entity eB sends cryptogram CZA to entity eA.
In a step S12, both entities calculate, each on its side, the random corresponding to the received cryptogram. Entity eA uses the group A key KA to calculate RAA=AES−1[KA] (CZA) and symmetrically for entity eB RZB=AES−1[KB] (CZB).
In step S13, a common session key KNZS is calculated, by entity eA from the calculated random RZA and from the random RNB stored in the token TNB. This session key enables the establishment of a secure channel in a step S14.
In a step S15, the secure channel is used by each entity to transfer a newly calculated token TN+1A and TZ+1B to the other entity in order to allow a future authentication with another entity involving the same groups.
For the same authentication the ratio of performances between the RHA and a RSA is about 1/3000 then a basic RHA authentication requires 2000 CPU cycles corresponding to 3 times an AES lasting 100 μs for a 20 MHz frequency.
FIG. 3 shows a half authentication using the RHA authentication. Here for example the entity eB is a service provider and eA is a customer requesting a service necessitating to check an attribute of entity eA. For example this attribute is “over 18 years”. If eA belongs to the attribute group, it would have the corresponding key KA.
After the half authentication, only the entity eA is authenticated by entity eB by establishing a secure channel between both and checking a challenge. The exchange and check of the challenge enables the evidence that an authentic secure channel is established and that the checked entity owns the right group key as well as the right arborescence.
Entity eB was previously provided by the group A with a token TA=[CA,RA] stored by the entity eB in a step H0. To check the attribute, the provider eB sends the cryptogram CA as stored to entity eA in a step H1. Using the group key KA, entity eA decrypts cryptogram CA in a step H2 and retrieve random RA. In a step H3, entity eA then establish a secure channel using said random RA which is also the one stored in token TA in eB. This secure channel is then used to send said random RA for further check by entity eB as, thus, eB can compare RA with the one in TA=[CA,RA].
When an entity does not have the right token for the last level, it may do nothing then the progression within the arborescence of groups in a remote entity will stop.
Considering the speed of the RHA protocol, a recursive approach can be implemented by performing recursively a symmetrical RHA between nested groups as described in FIG. 4.
This last figure shows two devices D1 and D2, each device grouping several entities, each entity being associated to one group. In this example, device D1 comprises entities eA and eC while device D2 comprises entities eB and eD. Entity eA corresponds for example to a service registration attribute and entity eB to an “over 18” attribute. When device D2 need to check “over 18” attributes, it needs to recursively build secure channel using the RHA authentication at each level. On FIG. 4, two levels only are represented using two session keys KABS and KCDS but much more levels could be implemented as the speed of RHA authentication is high.
By starting from the group encapsulating all other groups, the traceability (anonymity privacy property) is dependent on the cardinal of said group. The larger is the cardinal of the group, the highest is the performance related to non traceability.
Irrespective of the implemented protocol RSA/ECC or RHA, the recursive authentication into groups is required for ensuring the non traceability (surjection between an individual and a service having a large cardinal). The number of authentication is the same except the RHA is at least 3000 times faster than RSA/ECC. Nevertheless the number of exchanges is higher for the RHA than RSA/ECC.
Further alternative and advantageous solutions would, accordingly, be desirable in the art in order to reduce the number of exchanges. Indeed reducing the number of exchanges enables not to cancel the speed advantage of the RHA by wasting time in data exchanges which may be much longer than cryptography computations. It is particularly critical in contactless context like NFC. In such situation, using a small number or even a single exchange is crucial to reach acceptable duration of the authentication.